InfoMagic Internet Tools 1993 July/Internet Tools.iso/RockRidge/mail/pine/imap_archive/text0001.txt

Text File | 1993-07-02 | 5.9 KB | 124 lines

First, thank you to Mark Crispin for creating this list!

I'd like to ask what work is under way, or planned, for the next version
of IMAP2. In particular, are there plans for protocol support for:

  1. access to the host's quota control mechanism, where one exists
  2. password changing (for non-Kerberos sites)
  3. forwarding (automatic, i.e. access to '.forward' file or equivalent)
  ...
  4. simple X.500 interface
  5. forwarding (user-initiated, i.e. in a session)
  6. mail sending

(in decreasing order of importance - gap indicates where 'really needed'
changes to 'would be nice'). I can provide arguments for each of those on
request, and could probably work out upwards-compatible protocol
extensions, but I thought I'd check first to see if anyone else agrees. I
realise not all servers will want to / be able to provide any of these
functions, but many host systems can do, and it would be better to have
standardised protocol extensions rather than everyone inventing their own.
In particular, we see access to quota control (i.e. simply finding out what
percentage of quota has been used) as essential for naive users, since the
consequences of exceeding quotas can be utterly confusing.
--
Alasdair Grant                                      [phone]
MVS Systems Group / Small Systems Integration Group
University Computing Service,                [e-mail]
Pembroke St., Cambridge CB2 3QG, UK
From [e-mail]  Tue Sep  1 14:07:18 1992
Received: from mx1.cac.washington.edu by akbar.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA12245; Tue, 1 Sep 92 14:07:18 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA29395; Tue, 1 Sep 92 14:07:14 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA29389; Tue, 1 Sep 92 14:07:12 -0700
Date: Tue, 1 Sep 1992 13:38:30 -0700 (PDT)
From: Mark Crispin <[e-mail]>
Subject: re: IMAP2 futures?
To: IMAP Interest List <[e-mail]>
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

You raise a number of interesting questions:

>   1. access to the host's quota control mechanism, where one exists

This is difficult to do in any sort of general way.  One problem is that
different implementations have different interpretations of quotas.

On many systems, a quota is really some number of disk records (or clusters of
disk records).  Users often don't know their real quota; they are told some
number of `bytes' or `blocks' but they discover -- to their confusion -- that
they are out of quota even though the total number of `bytes' or `blocks' is
considerably less.

[Anecdote: A system I used 19 years ago gave users a `100 block' quota, saying
this was 64,000 characters.  However, it actually allocated (and charged!) in
clusters of 5 blocks, so the actual limit was 20 files, and only if the files
were less than 3200 characters each -- a 3201 character file was charged as 10
blocks.]

I agree that some mechanism to give users a handle on their disk quota
remotely is necessary.  It is important that any mechanism picked *not* be
biased towards on particular operating system's strategy, and that the data be
useful for a user.  Another issue is scoping; IMAP must not be allowed to get
`everything but the kitchen sink' put in, or we'll end up with an unwieldy
mess.  This is one reason why only minimal management was put into IMAP2bis
and why the more complex management issues were deferred to the Mail
Management Protocol.

So, let's put this on the table as a topic.

Modern-day c-client does detect and clean up properly when quota problems hit.

>   2. password changing (for non-Kerberos sites)

I believe that this was going to be considered as part of the Mail Management
Protocol developed by CMU.  I'd like to hear comments from the CMU hackers on
this.  I think that an environment in which users do not log into the IMAP
server as timesharing users will have to have the Mail Management Protocol
layer; the IMAP-only environment is for the `simple' configurations.

>   3. forwarding (automatic, i.e. access to '.forward' file or equivalent)

This is also a Mail Management Protocol issue for the same reasons.  CMU???

>   4. simple X.500 interface

This is one of those things that everyone talks about a lot, but it isn't all
that clear to me what it implies.  X.500 is supposed to solve all our problems
but then again X.400 was supposed to do so too.  I don't think that `simple'
and `X.anything' properly go together.  We'll need to do something about this,
but I'm taking a `wait and see' attitude until I understand the issues better.

>   5. forwarding (user-initiated, i.e. in a session)

Could you explain this?  I don't quite understand what you mean.  Do you mean
forwarding a message or altering your mail forwarding or ??

>   6. mail sending

This is a frequently asked request.  The IETF-REMMAIL group seems to have
sputtered out on this question, without achieving closure.  There are strong
arguments on both sides of the issue.  Although I am an `anti', I am
sympathetic to the problems the `pro' side faces; however, I have been totally
unsuccessful in playing Devil's Advocate for the `pro' side.

I suggest a review of the [e-mail] discussion to avoid rehashing
the same points over again.  It's an emotional topic; the `pro' side is
defending what they consider to be the side of simplicity (of a sort) and
authentication (again, of a sort), while the `anti' side defends simplicity
(of a different sort) and models which are possible only if mail access and
mail posting are not coupled.

If possible, I would like to see the discussion of this topic take place on
IETF-REMMAIL and not here.  I am agreeable to letting IMAP follow the
concensus of the IETF-REMMAIL group, should they achieve closure on the topic.

-- Mark --